View AT90SC7272C_394974.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

Atmel Confidential Proprietary
AT90SC7272C Security Target Lite Atmel Confidential Proprietary
Matthieu Robert (0450327)
TPG0054A (08 Dec 04)
Distribution 1. Approved Customers only (and internal release). 2. Valid Non Disclosure Agreement required.
Atmel makes no warranty for the use of its products, other than those expressly contained in the Company's standard warranty which is detailed in Atmel's Terms and Conditions located on the Company's web site. The Company assumes no responsibility for any errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice, and does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of Atmel are granted by the Company in connection with the sale of Atmel products, expressly or by implication. Atmel's products are not authorized for use as critical components in life support devices or systems. The security of any system in which the product is used will depend on the system's security as a whole. Where security or cryptography features are mentioned in this document this refers to features which are intended to increase the security of the product under normal use and in normal circumstances. All products are sold subject to Atmel's Terms & Conditions of Supply and the provisions of any agreements made between Atmel and the Customer. In ordering a product covered by this document the Customer agrees to be bound by those Terms & Conditions and agreements and nothing contained in this document constitutes or forms part of a contract (with the exception of the contents of this Notice). A copy of Atmel's Terms & Conditions of Supply is available on request. Atmel Corporation 2004
Matthieu Robert (0450327)
Contents
Section 1
AT90SC7272C Security Target Lite ............................................................ 9
1.1 Identification................................................................................................. 9 1.2 Overview ...................................................................................................... 9 1.3 Common Criteria Conformance Claim ....................................................... 10 1.4 Document Objective .................................................................................. 10 1.5 Document Structure ................................................................................... 10 1.6 Scope and Terminology............................................................................. 11 1.7 References ................................................................................................ 11 1.8 Revision History......................................................................................... 12
Section 2
Target of Evaluation Description................................................................ 13
2.1 Product Type ............................................................................................. 13 2.2 Smartcard Product Life-cycle..................................................................... 15 2.3 TOE Environment ...................................................................................... 17 2.4 TOE Logical Phases .................................................................................. 18 2.5 TOE Intended Usage ................................................................................. 18 2.6 General IT Features of the TOE ................................................................ 21
Section 3
TOE Security Environment ........................................................................ 23
3.1 Assets ........................................................................................................ 23 3.2 Assumptions .............................................................................................. 23 3.3 Threats....................................................................................................... 25 3.4 Organizational Security Policies ................................................................ 29
Section 4
Security Objectives .................................................................................... 31
4.1 Security Objectives for the TOE................................................................. 31 4.2 Security Objectives for the Environment.................................................... 34
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 3 of 68
AT90SC7272C Security Target Lite
Section 5
TOE Security Functional Requirements .................................................... 39
5.1 Functional Requirements Applicable to Phase 3 Only (Testing Phase) ......................................................................................... 39 5.2 Functional Requirements Applicable to Phases 3 to 7 .............................. 41 5.3 Functional Requirements Applicable to PMT in Phase 4 to 7 Only ........... 47 5.4 TOE Security Assurance Requirements .................................................... 48
Section 6
TOE Summary Specification...................................................................... 51
6.1 TOE Security Functions ............................................................................. 51 6.2 TOE Assurance Measures......................................................................... 57
Section 7
PP Claims .................................................................................................. 61
7.1 PP Reference............................................................................................. 61 7.2 PP Refinements ......................................................................................... 61 7.3 PP Additions .............................................................................................. 61
Appendix A
Glossary..................................................................................................... 63
Matthieu Robert (0450327)
4 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Figures
Figure 2-1
Smartcard Product Life Cycle ........................................................................... 16
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 5 of 68
AT90SC7272C Security Target Lite
Matthieu Robert (0450327)
6 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Tables
Table 2-1 Table 2-2 Table 3-1 Table 5-1 Table 6-1 Table 6-2
Smartcard Product Life-cycle ...................................................................... 15 Phases 4 to 7 Product Users ...................................................................... 20 Threats and Phases .................................................................................... 28 IFCSF_Policy .............................................................................................. 45 Relationship Between Security Requirements and Security Functions ...... 56 Relationship Between Assurance Requirements and Measures ................ 59
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 7 of 68
AT90SC7272C Security Target Lite
Matthieu Robert (0450327)
8 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Section 1
AT90SC7272C Security Target Lite
1.1
1 2
Identification
Title: AT90SC7272C Security Target Lite [ST-Lite] This Security Target Lite has been constructed with Common Criteria (CC) Version 2.1.
1.2
3
Overview
This Security Target Lite (ST-Lite) is conformant to the Protection Profile PP/9806, it is for a microcontroller (MCU) device with security features. The device is a member of a family of single chip MCU devices which are intended for use within Smartcard products. The family codename is AVR ASL4 and the `parent' device of the family, from which other family members will be derived, is the AT90SC19264RC. The AT90SC7272C MCU device (AT578B3) is being evaluated against the CC Smartcard Integrated Circuit Protection Profile PP/9806 to Evaluation Assurance Level 4 (EAL4) augmented with AVA_VLA.4, ADV_IMP.2 and ALC_DVS.2 under the Common Criteria maintenance scheme. Atmel Smart Card ICs, a division of ATMEL Corporation, is the developer and the sponsor for the AVR ASL4 evaluations. The devices in the AVR ASL4 family are based on the AVR RISC family of single-chip microcontroller devices. The AVR RISC family, with designed-in security features, is based on the industry-standard AVR low-power HCMOS core and gives access to the powerful instruction set of this widely used device. AVR ASL4 devices are equipped with Flash, RAM, ROM and EEPROM, cryptographic coprocessors, and a host of security features to protect device assets, making them suitable for a wide range of smartcard applications.
4
5
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 9 of 68
AT90SC7272C Security Target
1.3
6
Common Criteria Conformance Claim
This Security Target Lite is conformant to parts 2 and 3 of the Common Criteria, V2.1, as follows:
!
Part 2 conformant: the security functional requirements are based on those identified in part 2 of the Common Criteria. Part 3 conformant: the security assurance requirements are in the form of an EAL (assurance package) that is based upon assurance components in part 3 of the Common Criteria.
!
1.4
7
Document Objective
The purpose of this document is to satisfy the Common Criteria (CC) requirements for a Security Target Lite; in particular, to specify the security requirements and functions, and the assurance requirements and measures, in accordance with Protection Profile PP/9806, Smartcard Integrated Circuit V2.0. This ST-Lite is conformant to and against the AVR ASL4 devices with which it will be evaluated.
1.5
8
Document Structure
Section 1 introduces the Security Target Lite, and includes sections on terminology and references. Section 2 contains the product description and describes the TOE as an aid to the understanding of its security requirements and addresses the product type, the intended usage and the general features of the TOE. Section 3 describes the TOE security environment. Section 4 describes the required security objectives. Section 5 describes the TOE security functional requirements and the security assurance requirements. Section 6 describes the TOE security functions. Section 7 describes the Protection Profile (PP) claims. Appendix A provides a glossary of the terms and abbreviations.
9
10 11 12
13 14 15
Matthieu Robert (0450327)
10 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
AT90SC7272C Security Target Lite
1.6
16 17
Scope and Terminology
This document is based on the AT90SC7272C Technical Data Sheet [TD]. The term Target of Evaluation (TOE) is standard CC terminology and refers to the product being evaluated, the AT90SC7272C MCU device in this case. The TOE is subject to hardware evaluation only. Downloaded test software will be used for evaluation purposes but is outside the scope of the TOE. Description of how to use the security features can be found in [TD]. Security objectives are defined herein with labels in the form O.xx_xx. These labels are used elsewhere for reference. Similarly, threats, assumptions and organizational security policy are defined with labels of the form T.xx_xx, A.xx_xx, and P.xx_xx respectively. Hexadecimal numbers are prefixed by $, e.g. $FF is 255 decimal. Binary numbers are prefixed by %, e.g. %0001 1011 is decimal 27. An integer value may be expressed as a hexadecimal, binary or decimal number, whichever form is the most convenient.
18
19
1.7
20
References
The following list refers to the the latest revision of the following documents. Contact your local Atmel Sales office for further information.. [ESOF] AT90SC7272C Strength of Security Functions Analysis [STI] Standard Test Interface [TD] AT90SC7272C Technical Data (TPR0110) [TestROMDD] AT90SC7272C Evaluation Test Software Detailed Description [TestROMUG] AT90SC7272C Engineering ROM (Evaluation Mode) - User Guide [TMRE2] AT90SC7272C Test Software Specification (testmoderun E2 data) Test Description [TMR-User] AT90SC7272C Test Software Specification (testmoderun E2 data) - User Guide [PME] Aonach Package Mode Test [TBX] Toolbox V2.2 SC16 Crypto Coprocessor Library (TPR0112)
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 11 of 68
AT90SC7272C Security Target
1.8
Rev
Revision History
Date Description Originator
A
08 Dec 04
Initial release.
Atmel, EKB
Matthieu Robert (0450327)
12 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Section 2
Target of Evaluation Description
21
This part of the Security Target Lite (ST_Lite) describes the Target of Evaluation (TOE) as an aid to the understanding of its security requirements and address the product type, the intended usage and the general features of the TOE.
2.1
22
Product Type
The TOE is the single chip microcontroller unit to be used in a smartcard product, independent of the physical interface and the way it is packaged. Specifically, the TOE is the AT90SC7272C device from the AVR ASL4 family of smartcard devices. Generally, a smartcard product may include other optional elements (such as specific hardware components, batteries, capacitors, antennae) but these are not in the scope of this Security Target Lite. The devices in the AVR ASL4 family are based on ATMEL's AVR RISC family of single-chip microcontroller devices. The AVR RISC family, with designed-in security features, is based on the industry-standard AVR RISC low-power HCMOS core and gives access to the powerful instruction set of this widely used device. Different AVR ASL4 family members offer various options. The AVR ASL4 family of devices are designed in accordance with the ISO standard for integrated circuit cards (ISO 7816), where appropriate. Although the TOE evaluation is hardware only, the TOE requires embedded software to test the device and demonstrate certain security characteristics during the development phase. In the end-usage phase there will be no embedded test software in the TOE. Test software will be downloaded into the device EEPROM and be fully erased before devices leave the test environment. This test software is only used for the testing phase of the TOE life cycle and is outwith the scope of the evaluation. Test mode is permantly disabled by wafer saw. Any faulty devices returned by a customer can be put into package mode. This allows the test engineer to access the EEPROM to analyse the failure. On entering package mode the EEPROM is erased clearing any customer data. Package mode can only be entered on sawn wafers. The TOE widely uses ATMEL high density non volatile memories: it features 72K bytes of Flash program memory, 72K bytes of EEPROM program/data memory, 6K bytes of static RAM memory.
23
24
25
26
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 13 of 68
AT90SC7272C Security Target
27
The EEPROM includes 128 bytes of One Time Programmable (OTP) memory (64 bytes are byte-addressable; 64 bytes are bit-addressable) and a 384-byte bitaddressable area. The EEPROM includes contains both Atmel and customer specific data. The TOE also includes a 32bit Checksum Accelerator, a CRC-16 peripheral, a Random Number Generator, a fast hardware DES/3DES peripheral, and a crypto processor (SC16) and GF(2)N, with its basic Crypto ROM Toolbox library V2.2 [TBX] with cryptographic primitives (such as modular exponentiation) provided by Atmel [TBX]. Within the scope of the TOE are the following commands SHA-1, Modular Exponentiation, fast Modular Exponentiation,and Modular Exponentiation with CRT. Further information can not be given in the Security Target Lite due to its secure nature. The TOE includes security logic comprising detectors which monitor voltage, frequency, temperature and UV light. The TOE is equipped with logic peripherals including 2 timers, 2 serial ports, an ISO7816 interface and an ISO7816 controller. The TOE includes a powerful Firewall that protects all memories, peripheral and IO register accesses. This Firewall defines the user modes, Supervisor mode and NonSupervisor mode and many different address spaces.
28 29
30
31
32
Matthieu Robert (0450327)
14 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Target of Evaluation Description
2.2
33
Smartcard Product Life-cycle
The smartcard product life-cycle consists of 7 phases where the following authorities are involved.
Table 2-1 Smartcard Product Life-cycle
Phase 1
Smartcard software development
The smartcard software developer is in charge of the smartcard embedded software development and the specification of IC pre-personalization requirements, The IC designer designs the IC, develops IC dedicated software, provides information, software or tools to the smartcard software developer, and receives the software from the developer, through trusted delivery and verification procedures. From the IC design, IC dedicated software and smartcard embedded software, the IC designer constructs the smartcard IC database, necessary for the IC photomask fabrication. The IC manufacturer is responsible for producing the IC through three main steps:
! ! !
Phase 2
IC Development
Phase 3
IC manufacturing and testing
IC manufacturing IC testing IC pre-personalization
Phase 4
IC packaging and testing Smartcard product finishing process Smartcard personalization
The IC packaging manufacturer is responsible for the IC packaging and testing. The smartcard product manufacturer is responsible for the smartcard product finishing process and testing. The personalizer is responsible for the smartcard personalization and final tests. Other application software may be loaded onto the chip at the personalization process. The smartcard issuer is responsible for the smartcard product delivery to the smartcard end-user, and the end of life process.
Phase 5
Phase 6
Phase 7
Smartcard end-usage
34
The limits of the evaluation correspond to phases 2 and 3, including the phase 1 delivery and verification procedures and the TOE delivery to the IC packaging manufacturer ; procedures corresponding to phases 4, 5, 6 and 7 are outside the scope of the Security Target Lite. Nevertheless, in certain cases, it would be of great interest to include the phase 4 (IC packaging and testing), within the limits of the TOE. However, for the time being, this option remains outside the scope of this Security Target Lite.
35
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 15 of 68
AT90SC7272C Security Target
36
Figure 2-1 describes the Smartcard product life-cycle.
Phase 1 IC Personalization requirements Smartcard embedded software (not applicable) hardware only
Development Phase
Embedded software Pre-personalization data (not applicable hardware only)
IC sensitive information software, tools (not applicable hardware only)
Phase 2
IC Design
IC Dedicated Software Test Libraries
Product Construction
Smartcard IC Database Construction
Atmel Design Centre
IC Personalization requirements
IC Photomask Fabrication Phase 3 IC Manufacturing
Production Phase
IC Personalization requirements
IC Testing and Security Encoding
IC Packaging
Phase 4
Testing (1) Phase 5 Smartcard Product Finishing Process
User Phase
Testing (1) Phase 6 Personalization
Product Usage
Testing (1) Phase 7 Legend Limits of the development cycle Trusted delivery and verification procedures Smartcard Product End-Usage (1) Any faulty TOEs would be returned to the Atmel IC Testing Centre for analysis.
(1)
End of Life Process
Figure 2-1
Smartcard Product Life Cycle
Matthieu Robert (0450327)
16 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Target of Evaluation Description
37
These different phases may be performed at different sites; procedures on the delivery process of the TOE shall exist and be applied for every delivery within a phase or between phases. This includes any kind of delivery performed from phase 1 to phase 7, including:
! !
Intermediate delivery of the TOE or the TOE under construction within a phase Delivery of the TOE or the TOE under construction from one phase to the next
38
These procedures shall be compliant with the assumptions [A_DLV] developed in Section 3.2.2.
2.3
39
TOE Environment
Considering the TOE, three types of environments are defined:
! ! !
Development environment corresponding to phase 2 Production environment corresponding to phase 3 User environment, from phase 4 to phase 7
2.3.1
40
TOE Development Environment
To assure security, the environment in which the development takes place is made secure with controllable accesses having traceability. Access to the development building is strictly monitored by a security person. Visitors must sign a log book and record the time of arrival and time of departure to the building. All visitors are escorted by authorized personnel at all times. All authorized personnel involved fully understand the importance and the rigid implementation of the defined security procedures. The development begins with the TOE's specification. All parties in contact with sensitive information are required to abide by Non-Disclosure Agreements. Reticles and photomasks are generated from the verified IC database. The reticles and photomasks are then shipped securely to the wafer fab processing facilities.
41
42
2.3.2
43
TOE Production Environment
Production starts within the ATMEL Wafer Fabrication plant; here the silicon wafers undergo diffusion processing in 25-wafer lots. Computer tracking at wafer level throughout the process is achieved by a databsase based batch tracking system. The tracking system system is an on-line manufacturing tracking system which monitors the progress of the wafers through the fabrication cycle. After fabrication the wafers are sent to ATMEL test Fab where they are thinned to a pre-specified thickness and tested. ATMEL Test Fab test the TOE to assure conformance with the device specification. During the IC testing, security encoding is performed where some of the
44
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 17 of 68
AT90SC7272C Security Target
EEPROM bytes are programmed with the unique traceability information, and the customer software is loaded in the EEPROM.
45
The wafers are inked to separate the functional ICs from the non-functional ICs. Finally, the wafers are sawn and then shipped to the customer.
2.3.3
46 47 48
TOE User Environment
The TOE user environment is the environment of phases 4 to 7. At phases 4, 5, and 6, the TOE user environment is a controlled environment. Following the sawing step, the wafers are split into individual dies. The good ICs are assembled into modules in a module assembly plant. Further testing is carried out followed by the shipment of the modules to the smartcard product manufacturer (embedder) by means of a secure carrier. Additional testing occurs followed by smartcard personalization, retesting and then delivery to the smartcard issuer.
End-user environment (Phase 7)
49
50
51
Smartcards are used in a wide range of applications to assure authorized conditional access. Examples of such are Pay-TV, Banking Cards, Portable communication SIM cards, Health cards, Transportation cards. Therefore, the user environment covers a wide spectrum of very different functions, thus making it difficult to avoid or monitor any abuse of the TOE.
52
2.4
53
TOE Logical Phases
During its construction usage, the TOE may be under several life logical phases. These phases are sorted under a logical controlled sequence. The change from one phase to the next shall be under the TOE control.
2.5
54
TOE Intended Usage
The TOE can be incorporated in several applications such as:
!
Banking and finance market for credit/debit cards, electronic purse (stored value cards) and electronic commerce. Network based transaction processing such as mobile phones (GSM SIM cards), pay-TV (subscriber and pay-per-view cards), communication highways (Internet access and transaction processing).
!
Matthieu Robert (0450327)
18 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Target of Evaluation Description
! ! !
Transport and ticketing market (access control cards). Governmental cards (ID-cards, healthcards, driver license etc). Multimedia commerce and Intellectual Property Rights protection.
55
During the phases 1, 2, 3, the product is being developed and produced. The administrators are the following:
!
The IC designer: Authorized staff who work for the developer, and who design the MCU (such development staff are trusted and privileged users).
!
The IC manufacturer: Authorized staff who work for the developer and who manufacture and test the MCU (such manufacturing staff are trusted and priviliged users).
!
The smartcard dedicated software developer: Authorized staff who work for the developer and who develop the dedicated test software and crypto libraries (such development staff are trusted and priviliged users).
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 19 of 68
AT90SC7272C Security Target
56
Table 2-2 lists the users of the product during phases 4 to 7.
Table 2-2 Phases 4 to 7 Product Users
Phase 4
! ! !
Packaging manufacturer (administrator) Smartcard embedded software developer System integrator, such as the terminal software developer
Phase 5
! ! !
Smartcard product manufacturer (administrator) Smartcard embedded software developer System integrator, such as the terminal software developer
Phase 6
! !
Personalizer (administrator) Customers who, before manufacture, determine the MCU's mask options and the initial memory contents (i.e. the application program), and who, after manufacture, incorporate the MCU into devices. Customers are trusted and privileged users. Smartcard issuer (administrator). Smartcard embedded software developer. System integrator, such as the terminal software developer.
! ! !
Phase 7
! !
Smartcard issuer (administrator) Smartcard end-user, who use devices incorporating the MCU. End-users are not trusted and may attempt to attack the MCU. Smartcard software developer. System integrator, such as the terminal software developer. The IC manufacturer and the smartcard product manufacturer may also receive ICs for analysis, should problems occur during the smartcard usage.
! !
Note
57
The MCU may be used in the following modes: a) Test mode, in which the MCU runs under the control of dedicated test software written to EEPROM via a test interface, and in conjunction with stimulus provided by an external test system. This mode is intended to be used solely by authorized development staff. b) User mode, in which the MCU runs under control of the smartcard embedded software. It is intended that customers and end-users will always use the MCU in user mode.
Matthieu Robert (0450327)
20 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Target of Evaluation Description
58
During the initial part of the manufacturing process, the MCU is set to test mode. Authorized development staff then test the MCU. After testing, test mode is permanently disabled by sawing off the test pads, and the MCU is set to user mode. Package Mode is a mode similar to Test Mode for testing returns from Phases 4-7. Package mode runs a limited subset of test commands via a test interface. This mode is intended to be used solely by authorized staff. If a faulty TOE is returned from the field then analysis can be done either in user mode, or package mode by an authorized test engineer. Once manufactured, the MCU operates by executing the smartcard embedded software, which is stored in Flash. The contents of the Flash can only be modified by code executing in Flash, whereas the contents of the EEPROM can, in general, be written to or erased, under the control of the smartcard embedded software. The EEPROM includes OTP bytes, which can be used to store security-related information such as cryptographic keys. The OTP bytes cannot be erased in user mode. The FireWall (Memories and Peripherals Protection Unit) allows the smartcard embedded software to prevent read/write/execute access to (parts of) Flash, EEPROM, RAM, Crypto ROM and peripherals from EEPROM. The ISO7816 compliant I/O port can be used to pass data to or from the MCU. The application program determines how to interpret the data.
59
60
61
62
63
64
2.6
65
General IT Features of the TOE
The TOE IT functionalities consist of data storage and processing such as:
!
Arithmetic functions (e.g. incrementing counters in electronic purses, calculating currency conversion in electronic purses) Data communication Cryptographic operations (e.g. data encryption, digital signature verification)
! !
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 21 of 68
AT90SC7272C Security Target
Matthieu Robert (0450327)
22 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Section 3
TOE Security Environment
66
This section describes the security aspects of the environment in which the TOE is intended to be used, and addresses the description of the assumptions, the assets to be protected, the threats, and the organizational security policies.
3.1
67
Assets
Assets are security relevant elements of the TOE that include the:
!
Application data of the TOE comprising the IC pre-personalization requirements, such as the Flash, EEPROM, the Crypto ROM and OTP contents. Smartcard embedded software IC specification, design, development tools and technology
! !
68 69
Therefore, the TOE itself is an asset. Assets must be protected in terms of confidentiality, integrity and availability.
3.2
70
Assumptions
It is assumed that this section concerns the following items:
!
Due to the definition of the TOE limits, any assumption for the smartcard software development (phase 1 is outside the scope of the TOE) Any assumption from phases 4 to 7 for the secure usage of the TOE, including the TOE trusted delivery procedures
!
71
Security is always dependent on the whole system: the weakest element of the chain determines the total system security. Assumptions described hereafter must be considered for a secure system using smartcard products:
! ! ! !
Assumptions on phase 1 Assumptions on the TOE delivery process (phases 4 to 7) Assumptions on phases 4-5-6 Assumptions on phase 7
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 23 of 68
AT90SC7272C Security Target
3.2.1
Assumptions on Phase 1 The smartcard embedded software shall be designed in a secure manner, that is focusing on integrity of program and data. Procedures dealing with physical, personnel, organizational, technical measures for the confidentiality and integrity of smartcard embedded software (e.g. source code and any associated documents) and IC designer proprietary information (tools, software, documentation.) shall exist and be applied in software development.
A.SOFT_ARCHI
A.DEV_ORG
3.2.2
72
Assumptions on the TOE Delivery Process (Phases 4 to 7)
Procedures shall guarantee the control of the TOE delivery and storage process and conformance to its objectives as described in the following assumptions. A.DLV_PROTECT A.DLV_AUDIT Procedures shall ensure protection of TOE material and information under delivery and storage. . Procedures shall ensure that corrective actions are taken in case of improper operation in the delivery process and storage. Procedures shall ensure that people dealing with the procedure for delivery have got the required skill.
A.DLV_RESP
3.2.3
Assumptions on Phases 4 to 6 It is assumed that appropriate functionality testing of the IC is used in phases 4, 5 and 6. It is assumed that security procedures are used during all manufacturing and test operations through phases 4, 5, 6 to maintain confidentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unauthorized use)..
A.USE_TEST A.USE_PROD
3.2.4
Assumptions on Phase 7 It is assumed that secure communication protocols and procedures are used between smartcard and terminal. It is assumed that the integrity and confidentiality of sensitive data stored/handled by the system (terminals, communications...) is maintained.
A.USE_DIAG A.USE_SYS
Matthieu Robert (0450327)
24 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Security Environment
3.3
73
Threats
The TOE as defined in Section 2 is required to counter the threats described hereafter; a threat agent wishes to abuse the assets either by functional attacks, environmental manipulations, specific hardware manipulations or by any other types of attacks. Threats have to be split in:
! !
74
Threats against which specific protection within the TOE is required (class I), Threats against which specific protection within the environment is required (class II).
3.3.1
Unauthorized Full or Partial Cloning of the TOE Functional cloning of the TOE (full or partial) appears to be relevant to any phases of the TOE life-cycle, from phase 1 to phase 7. Generally, this threat is derived from specific threats combining unauthorized disclosure, modification or theft of assets at different phases.
T.CLON
3.3.2
75
Threats on Phase 1 (Delivery and Verification Procedures)
During phase 1, three types of threats have to be considered: a) Threats on the smartcard's embedded software and its environment of development, such as:
! !
Unauthorized disclosure Modification or theft of the smartcard embedded software and any additional data at phase 1.
Considering the limits of the TOE, these previous threats are outside the scope of this Security Target Lite. b) Threats on the assets transmitted from the IC designer to the smartcard software developer during the smartcard development. c) Threats on the smartcard embedded software and any additional application data transmitted during the delivery process from the smartcard embedded software developer to the IC designer.
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 25 of 68
AT90SC7272C Security Target
76
The previous types b and c threats are described hereafter. T.DIS_INFO Unauthorized disclosure of the assets delivered by the IC designer to the smartcard software developer such as sensitive information on IC specification, design and technology, software and tools if applicable. Unauthorized disclosure of the smartcard embedded software and any additional application data (such as IC pre-personalization requirements) during the delivery process to the IC designer. Unauthorized modification of the smartcard embedded software and any additional application data (such as IC pre-personalization requirements) during the delivery process to the IC designer. Theft of the smartcard embedded software and any additional application data (such as IC pre-personalization requirements) during the delivery process to the IC designer.
T.DIS_DEL
T.MOD_DEL
T.T_DEL
3.3.3
77
Threats on Phases 2 to 7
During these phases, the assumed threats could be described in three types:
! ! !
Unauthorized disclosure of assets Theft or unauthorized use of assets Unauthorized modification of assets
Unauthorized disclosure of assets
78
This type of threats covers unauthorized disclosure of assets by attackers who may possess a wide range of technical skills, resources and motivation. Such attackers may also have technical awareness of the product. T.DIS_DESIGN Unauthorized disclosure of IC design. This threat covers the unauthorized disclosure of proprietary elements such as IC specification, IC design, IC technology detailed information, IC hardware security mechanisms specifications. T.DIS_SOFT Unauthorized disclosure of smartcard embedded software and data such as access control, authentication system, data protection system, memory partitioning, cryptographic programs.
Matthieu Robert (0450327)
26 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Security Environment
T.DIS_DSOFT
Unauthorized disclosure of IC dedicated software. This threat covers the unauthorized disclosure of IC dedicated software including security mechanisms specifications and implementation.
T.DIS_TEST T.DIS_TOOLS
Unauthorized disclosure of test information such as full results of IC testing including interpretations. Unauthorized disclosure of development tools. This threat covers potential disclosure of IC development tools and testing tools (analysis tools, microprobing tools).
T.DIS_PHOTOMASK
Unauthorized disclosure of photomask information, used for photoengraving during the silicon fabrication process.
Theft or unauthorized use of assets
79
Potential attackers may gain access to the TOE and perform operations for which they are not authorized. For example, such attackers may personalize the product in an unauthorized manner, or try to gain fraudulous access to the smartcard system. T.T_SAMPLE T.T_PHOTOMASK T.T_PRODUCT Theft or unauthorized use of TOE silicon samples, for example, bond out chips. Theft or unauthorized use of TOE photomasks. Theft or unauthorized use of smartcard products.
Unauthorized modification of assets
80
The TOE may be subjected to different types of logical or physical attacks which may compromise security. Due to the intended usage of the TOE (the TOE environment may be hostile), the TOE security parts may be bypassed or compromised reducing the integrity of the TOE security mechanisms and disabling their ability to manage the TOE security. This type of threat includes the implementation of malicious trojan horses. T.MOD_DESIGN Unauthorized modification of IC design. This threat covers the unauthorized modification of IC specification, IC design including IC hardware security mechanisms specifications and realization. T.MOD_PHOTOMASK T.MOD_DSOFT T.MOD_SOFT Unauthorized modification of TOE photomasks. Unauthorized modification of IC dedicated software including modification of security mechanisms. Unauthorized modification of smartcard embedded software and data.
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 27 of 68
AT90SC7272C Security Target
81
Table 3-1 indicates the relationships between the smartcard phases and the threats.
Table 3-1 Threats and Phases
Threats Functional cloning T.CLON T.DIS_INFO T.DIS_DEL T.DIS_SOFT T.DIS_DSOFT T.DIS_DESIGN T.DIS_TOOLS T.DIS_PHOTOMASK T.DIS_TEST
Phase 1 Class II Class II Class II
Phase 2 Phase 3 Class II
Phase 4 Phase 5 Phase 6 Phase 7 Class I Class I Class I
Class I/II Class I
Unauthorized disclosure of assets
Class II Class II Class II Class II Class II
Class I/II Class I Class I/II Class I Class I/II Class I Class II Class II Class I/II Class I
Class I Class I Class I
Class I Class I Class I
Class I Class I Class I
Class I
Class I
Theft or unauthorized use of assets T.T_DEL T.T_SAMPLE T.T_PHOTOMASK T.T_PRODUCT Unauthorized modification threats T.MOD_DEL T.MOD_SOFT T.MOD_DSOFT T.MOD_DESIGN T.MOD_PHOTOMASK Class II Class II Class II Class II Class II Class I/II Class I Class I/II Class I Class I/II Class I Class II Class I Class I Class I Class I Class I Class I Class I Class I Class I Class II Class II Class II Class I/II Class I Class II Class I/II Class I Class I Class I Class I Class I
Matthieu Robert (0450327)
28 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Security Environment
3.4
82
Organizational Security Policies
An organizational security policy is mandatory for the smartcard product usage. The specifications of organizational security policies essentially depend on the applications in which the TOE is incorporated. However, it was found relevant to address the following organizational security policy with the TOE because most of the actual Smart Card secure applications make use of cryptographic standards. P.CRYPTO Cryptographic entities, data authentication, and approval functions must be in accordance with ISO, associated industry, or organizational standards or requirements. Various cryptographic algorithms and mechanisms, such as triple DES, AES, RSA, MACs, and Digital Signatures, are accepted international standards. These, or others in accordance with industry or organizational standards of similar maturity and definition, should be used for all cryptographic operations in the TOE. These cryptographic operations are used for instance to support establishment and control of a trusted channel between the TOE and the outside environment. To support these cryptographic functions, the TOE should supply Random Number Generation (RNG) with sufficient unpredictability and entropy. The TOE shall ensure that no information about the produced random numbers is available to an attacker since they might be used for instance to generate cryptographic keys.
83
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 29 of 68
AT90SC7272C Security Target
Matthieu Robert (0450327)
30 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Section 4
Security Objectives
84
The security objectives of the TOE cover principally the following aspects:
! !
Integrity and confidentiality of assets Protection of the TOE and associated documentation during development and production phases
4.1
85
Security Objectives for the TOE
The TOE shall use state of art technology to achieve the following IT security objectives: O.TAMPER The TOE must prevent physical tampering with its security critical parts. The TOE must provide protection against disclosure of User data, against disclosure/reconstruction of the Smartcard Embedded Software or against disclosure of other critical operational information. This includes protection against direct micro-probing of signals not connected to bonding pads, but also other contact or contactless probing techniques such as laser probing or electromagnetic sensing. Most of these techniques require a prior reverse engineering of parts of the device to understand its architecture and its security functions. This also includes protection against inherent information leakage (for example shape of signals, power consumption) on the device external interfaces (for example clock, supply, I/O lines) that could be used to disclose confidential data, as well as forced information leakage caused by induced malfunction or physical manipulation
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 31 of 68
AT90SC7272C Security Target
O.CLON
The TOE functionality needs to be protected from cloning. The TOE must include means to prevent an attacker from reproducing the smartcard functionality. Most of these techniques require a prior reverse engineering of parts of the device to understand its architecture and its security functions.
O.OPERATE
The TOE must ensure the continued correct operation of its security functions. The TOE must include protection against the use of stolen silicon samples or products that would ease an attacker gaining fraudulous access to the smartcard system. The TOE must also provide mechanisms to avoid the unauthorized modification of the security functions or software and data, by using the device test commands for instance, or by using uncontrolled/unauthentified software access to memories. The TOE must prevent its operation outside the normal operating conditions where reliability and secure operation has not been proven or tested. This is to prevent errors. The environmental conditions may include voltage, clock frequency, temperature, or external energy fields
O.FLAW
The TOE must not contain flaws in design, implementation or operation. The TOE design must include protection against modification of its security mechanisms (for example detectors or memory protections) that would lead to bypass or reduce their integrity, and therefore open security holes that could be used to access embedded software and data. The TOE design must also provide protection against modification of its embedded software that would lead to bypass or reduce the integrity of some software controlled security mechanisms (for example memory areas definition), and therefore open security holes that could be used to access embedded software and data.
O.DIS_MECHANISM
The TOE shall ensure that the hardware security mechanisms are protected against unauthorized disclosure. The TOE must be designed and fabricated so that it requires a high combination of complex equipment, knowledge, skill and time to derive detailed designed information or other information which could be used to compromise security through physical attacks.
Matthieu Robert (0450327)
32 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Security Objectives
O.DIS_MEMORY
The TOE shall ensure that sensitive information stored in memories is protected against unauthorized access. The TOE must provide protection against unauthorized access to embedded software and data stored in memories, either using test commands, or by some embedded software (for instance a non-supervisor user application) that would try to dump the memories protected by the Firewall programmation (for instance the supervisor program and/or data), or even by some physical attacks.
O.MOD_MEMORY
The TOE shall ensure that sensitive information stored in memories is protected against any corruption or unauthorized modification. The TOE must provide protection against unauthorized access to embedded software and data stored in memories, either using test commands, or by some embedded software (for instance a non-supervisor user application) that would try to modify the memories protected by the Firewall programmation (for instance the supervisor program and/or data), or even by some physical attacks.
O.CRYPTO
Cryptographic capability shall be available for users to maintain integrity and confidentiality of sensitive data. The TOE must provide hardware implementation of some cryptographic algorithms that can be used by the embedded software in conjunction with appropriate counter-measure to achieve cryptographic operations (for instance encryption, decryption, integrity checking, signature, key generation, for algorithms such as DES, TDES, RSA, SHA-1, DSA, Elliptic Curves, ...). These cryptographic operations are used for instance to support establishment and control of a trusted channel between the TOE and the outside environment, or protect confidential data stored in the TOE memories. The TOE must also provide random number generation and ensure the cryptographic quality of random number generation. For example, random numbers shall not be predictable and shall have a sufficient entropy. The TOE must ensure that no information about the produced random numbers is available to an attacker since they might be used for instance to generate cryptographic keys.
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 33 of 68
AT90SC7272C Security Target
4.2
Security Objectives for the Environment
4.2.1
Objectives on Phase 1 The smartcard IC designer must have procedures to control the sales, distribution, storage and usage of the software and hardware development tools and classified documents, suitable to maintain the integrity and the confidentiality of the assets of the TOE. It must be ensured that:
!
O.DEV_DIS
Tools are only delivered to the parties authorized personnel. Confidential information such as data sheets and general information on defined assets are only delivered to the parties authorized personnel on the basis of need-to-know.
!
O.SOFT_DLV
The smartcard embedded software must be delivered from the smartcard embedded software developer (Phase 1) to the IC designer through a trusted delivery and verification procedure that shall be able to maintain the integrity of the software and its confidentiality, if applicable. To achieve the level of security required by this Security Target Lite, the smartcard embedded software shall use IC security features and security mechanisms (for example, sensors) as specified in the smartcard IC documentation [TD]. The smartcard embedded software shall be designed in a secure manner, by using exclusively software development tools (compilers, assemblers, linkers, simulators etc.) and software-hardware integration testing tools (emulators) that will grant the integrity of program and data.
O.SOFT_MECH
O.DEV_TOOLS
Matthieu Robert (0450327)
34 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Security Objectives
4.2.2
Objectives on Phase 2 (Development Phase) Embedded software shall be accessible only by authorized personnel within the IC designer on the basis of need-to-know. IC specifications, detailed design, IC databases, schematics/layout or any further design information shall be accessible only by authorized personnel within the IC designer on the basis of need-to-know (physical, personnel, organizational, technical procedures). Any IC dedicated software specification, detailed design, source code or any further information shall be accessible only by authorized personnel within the IC designer on the basis of need-to-know. Physical, personnel, organizational, technical procedures during photomask fabrication (including deliveries between photomasks manufacturer and IC manufacturer) shall ensure the integrity and confidentiality of the TOE. Details of hardware security mechanisms shall be accessible only by authorized personnel within the IC designer on the basis of need-to-know. Security relevant technology information shall be accessible only by authorized personnel within the IC designer on the basis of need-to-know.
O.SOFT_ACS O.DESIGN_ACS
O.DSOFT_ACS
O.MASK_FAB
O.MECH_ACS
O.TI_ACS
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 35 of 68
AT90SC7272C Security Target
4.2.3
Objectives on Phase 3 (Manufacturing Phase) The manufacturing process shall ensure that protection of the TOE from any kind of unauthorized use such as tampering or theft. During the IC manufacturing and test operations, security procedures shall ensure the confidentiality and integrity of:
!
O.TOE_PRT
TOE manufacturing data (to prevent any possible copy, modification, retention, theft or unauthorized use). TOE security relevant test programs, test data, databases and specific analysis methods and tools.
!
These procedures shall define a security system applicable during the manufacturing and test operations to maintain confidentiality and integrity of the TOE by control of:
! ! !
Packaging and storage. Traceability. Storage and protection of manufacturing process specific assets (such as manufacturing process documentation, further data, or samples) Access control and audit to tests, analysis tools, laboratories, and databases. Change/modification in the manufacturing equipment, management of rejects.
!
!
O.IC_DLV
The delivery procedures from the IC manufacturer shall maintain the integrity and confidentiality of the TOE and its assets.
Matthieu Robert (0450327)
36 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Security Objectives
4.2.4
Objectives on the TOE Delivery Process (Phases 4 to 7) Procedures shall ensure protection of TOE material and information under delivery, including the following objectives:
! ! !
O.DLV_PROTECT
Non-disclosure of any security relevant information. Identification of the elements under delivery. Meet confidentiality rules (confidentiality level, transmittal form, reception acknowledgement). Physical protection to prevent external damage. Secure storage and handling procedures are applicable for all TOEs (including rejected TOEs). Traceability of TOE during delivery including the following parameters:
! ! !
! !
!
Origin and shipment details. Reception, reception acknowledgement. Location material and information.
O.DLV_AUDIT
Procedures shall ensure that corrective actions are taken in the event of improper operation in the delivery process (including, if applicable any non-conformance to the confidentiality convention) and highlight all non conformance to this process. Procedures shall ensure that people (shipping department, carrier, reception department) dealing with the procedure for delivery get the required skill, training and knowledge to meet the procedure requirements, and to act in full accordance with the above expectations.
O.DLV_RESP
4.2.5
Objectives on Phase 4 to 6 Appropriate functionality testing of the IC shall be used in phases 4 to 6. During all manufacturing and test operations, security procedures shall be used through phases 4, 5, 6, to maintain confidentiality and integrity of the TOE and of its manufacturing and test data.
O.TEST_OPERATE
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 37 of 68
AT90SC7272C Security Target
4.2.6
Objectives on Phase 7 Secure communication protocols and procedures shall be used between smartcard and terminal. The integrity and the confidentiality of sensitive data stored or handled by the system (terminals, communications....) shall be maintained.
O.USE_DIAG O.USE_SYS
Matthieu Robert (0450327)
38 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Section 5
TOE Security Functional Requirements
86
The TOE security functional requirements define the functional requirements for the TOE using only functional requirements components drawn from the Common Criteria part 2. The minimum strength of function level for the TOE security requirements is SOF-high.
87
5.1
Functional Requirements Applicable to Phase 3 Only (Testing Phase)
5.1.1
88
User Authentication Before any Action (FIA_UAU.2)
The TOE security functions shall require each user to be successfully authenticated before allowing any other TOE security functions-mediated actions on behalf of that user.
5.1.2
89
User Identification Before any Action (FIA_UID.2)
The TOE security functions shall require each user to identify itself before allowing any other TOE security functions mediated actions on behalf of that user.
5.1.3
90
User Attribute Definition (FIA_ATD.1)
The TOE security functions shall maintain the following list of security attributes belonging to individual users:
! ! ! ! ! ! ! ! !
Test mode access right Package mode access right Read Flash access right Write Flash access right Execute Flash access right Read EEPROM access right Write EEPROM access right Execute EEPROM access right Read Crypto ROM access right
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 39 of 68
AT90SC7272C Security Target
! ! ! ! ! ! ! !
Write Crypto ROM access right Execute Crypto ROM access right Read RAM access right Write RAM access right Execute RAM access right Read access right to peripherals and IO registers Write access right to peripherals and IO registers Execute access right to peripherals and IO registers
5.1.4
91
TOE Security Functions Testing (FPT_TST.1)
The TOE security functions shall:
!
Run a suite of self tests at the request of the authorized user to demonstrate the correct operation of the TOE security functions. Provide authorized users with the capability to verify the integrity of TOE security functions data. Provide authorized users with the capability to verify the integrity of stored TOE security functions executable code.
!
!
5.1.5
92
Stored Data Integrity Monitoring (FDP_SDI.1)
The TOE security functions shall monitor user data stored within the TOE scope of control for integrity errors on all objects, based on the following attributes:
! ! ! !
Test signature from Flash Test signatures from, and contents of, RAM Test signature from Crypto ROM Test signature from EEPROM
Matthieu Robert (0450327)
40 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Security Functional Requirements
5.2
Functional Requirements Applicable to Phases 3 to 7
5.2.1
93
Management of Security Functions Behaviour (FMT_MOF.1)
The TOE security functions shall restrict the ability to enable the functions available in Test Mode to the Test Mode Entry (TME) administrator. The TOE security functions shall restrict the ability to disable the functions available in Test Mode to the Test Mode Entry (TME) administrator.
94
5.2.2
95
Management of Security Attributes (FMT_MSA.1)
The TOE security functions shall enforce the ACSF_Policy (Access Control Security Functions Policy) and IFCSF_Policy (Information Flow Control Security Functions Policy) to restrict the ability to access the security attribute to TME administrator and Firewall supervisor, non-supervisor, Pacakge modes. The ACSF_Policy is not described in this document see Table 5-1 for further information on the IFCSF_Policy.
Note
5.2.3
96
Security Roles (FMT_SMR.1)
The TOE security functions shall maintain the role of:
! ! ! !
TME administrator Supervisor Non-supervisor PME administrator
97
The TOE security functions shall be able to associate users with roles.
5.2.4
98
Specification of Management Functions (FMT_SMF.1)
The TOE security functions shall be capable of performing the following security management functions:
!
Control entry into and disabling of test mode and entry into user mode and package mode. Define the user modes, (Supervisor, Non-supervisor) address space parameters. Which controls the software access between each program user regions, but also between the program user and the data user regions.
!
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 41 of 68
AT90SC7272C Security Target
5.2.5
99
Static Attribute Initialization (FMT_MSA.3)
The TOE security functions shall:
!
Enforce the ACSF_Policy and IFCSF_Policy to provide restrictive default values for security attributes that are used to enforce the security functions policy Allow the TME administrator to specify alternate initial values to override the default values when an object or information is created
!
5.2.6
100
Complete Access Control (FDP_ACC.2)
The TOE security functions shall enforce the ACSF_Policy on:
! ! !
TME administrator, Supervisor, Non-supervisor, PME administrator. Flash, EEPROM, RAM, Crypto ROM, peripheral and IO registers. And all operations among subjects and objects covered by the security functions policy.
101
The TOE security functions shall ensure that all operations between any subject in the TOE scope of control and any object within the TOE scope of control are covered by an access control security functions policy.
5.2.7
102
Security Attribute Based Access Control (FDP_ACF.1)
The TOE security functions shall enforce the ACSF_Policy to objects based on:
! ! ! ! ! ! ! ! ! ! ! ! ! ! !
Read Flash access right Write Flash access right Execute Flash access right Read EEPROM access right Write EEPROM access right Execute EEPROM access right Read Crypto ROM access right Write Crypto ROM access right Execute Crypto ROM access right Read RAM access right Write RAM access right Execute RAM access right Read peripheral and IO registers access right Write peripheral and IO registers access right Execute peripheral and IO registers access right
Matthieu Robert (0450327)
42 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Security Functional Requirements
103
The TOE security functions shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed. Firewall rules, that are not disclosed in this ST-Lite document. The TOE security functions shall explicitly authorize access of subjects to objects based on the following additional rules: no additional rules.
104 105
5.2.8
106
Subset Information Flow Control (FDP_IFC.1)
The TOE security functions shall enforce the IFCSF_Policy on TME administrator and PME administrator, test commands and test operations that cause controlled information to flow between the:
! ! ! ! ! ! !
Flash and the Test Mode Entry administrator Flash and the Package Mode Entry administrator EEPROM and the Test Mode Entry administrator EEPROM and the Package Mode Entry administrator Crypto ROM and the Test Mode Entry administrator RAM and the Test Mode Entry administrator Peripheral and IO registers and the Test Mode administrator
5.2.9
107
Simple Security Attributes (FDP_IFF.1)
The TOE security functions shall enforce the IFCSF_Policy based on the following types of subject and information security attributes: test command syntax. The TOE security functions shall:
!
108
Permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: test command syntax rules. Enforce no additional information flow control security functions policy rules. Provide no additional security functions policy capabilities.
! !
109
The TOE security functions shall explicitly authorize an information flow based on the following rules: Test command syntax rules, based on test command syntax, that explicitly authorize information flows between TME administrator and:
! ! ! !
110
Flash EEPROM Crypto ROM RAM
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 43 of 68
AT90SC7272C Security Target
!
Peripheral and IO registers
111
Test command syntax rules, based on test command syntax, that explicitly authorize information flows between PME administrator and:
! !
EEPROM Flash
112
The TOE security functions shall explicitly deny an information flow based on the following rules: Test command syntax rules, based on test command syntax, that explicitly deny information flows between TME administrator and:
! ! ! ! !
113
Flash EEPROM Crypto ROM RAM Peripheral and IO registers
114
Test command syntax rules, based on test command syntax, that explicitly deny information flows between PME administrator and:
! ! ! ! !
Flash EEPROM Crypto ROM RAM Peripheral and IO registers
Matthieu Robert (0450327)
44 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Security Functional Requirements
IFCSF_Policy
Table 5-1 IFCSF_Policy
Rules Attribute TME Administrator PME Administrator
Test command syntax rules Test command syntax Data flow (1) Data flow (2)
(1)
All information about possible data flow and Test command syntax can be found in [STI], [TMR-USER], [TestROMUG], [TestROMDD] and [TMRE2]. (2) All information about possible data flow and Test command syntax can be found in [STI], [PME].
5.2.10
115
Potential Violation Analysis (FAU_SAA.1)
The TOE Security Functions shall be able to apply a set of rules in monitoring the audited events and based upon these rules indicate a potential violation of the TOE Security Policy. The TOE security functions shall enforce the following rules for monitoring audited events: a) Accumulation or combination of abnormal environmental conditions (Supply voltage, clock input frequency, temperature, UV light) known to indicate a potential security violation. b) Accumulation or combination of physical tampering (Micro-probing, critical FIB modification) known to indicate a potential security violation. c) Accumulation or combination of Firewall violations (user trying to illegally access controlled memories or objects, user trying to execute illegal opcodes) known to indicate a potential security violation. d) Accumulation of watchdog violations known to indicate a potential security violation. e) No other rules.
116
5.2.11
117
Unobservability (FPR_UNO.1)
The TOE security functions shall ensure that any users are unable to observe the operation of TOE internal activity on TOE objects by authorized users or subjects.
5.2.12
118
Notification of Physical Attack (FPT_PHP.2)
The TOE security functions shall:
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 45 of 68
AT90SC7272C Security Target
!
Provide unambiguous detection of physical tampering that might compromise the TOE security functions. Provide the capability to determine whether physical tampering with the TOE security functions's devices or TOE security functions's elements has occurred.
!
119
For values of voltage, clock input frequency, temperature and UV light which go outside acceptable bounds, for micro-probing and critical FIB modification, for Firewall rules violations (including illegal opcodes), and for watchdog violations, the TOE security functions shall monitor the devices and elements and notify the P0-supervisor when physical tampering with the TOE security functions' devices or TOE security functions' elements has occurred.
5.2.13
120
Resistance to Physical Attack (FPT_PHP.3)
The TOE security functions shall resist tampering of voltage, clock input frequency, temperature, UV light, micro-probing, critical FIB modification, Firewall rules violations (including illegal opcodes), and watchdog violations to the TOE and its security functions by responding automatically such that the TOE security policy is not violated.
5.2.14
121
Cryptographic Operation (FCS_COP.1)
The TSF shall perform hardware data encryption and decryption in accordance with the:
!
DES cryptographic algorithm using 56-bit cryptographic key sizes that meets the Data Encryption Standard (DES), FIPS PUB 46-3, 25th October, 1999. Triple Data Encryption Standard (TDES) cryptographic algorithm using 112-bit cryptographic key sizes that meets the E-D-E two-key triple-encryption implementation of the Data Encryption Standard, FIPS PUB 46-3, 25th October, 1999. Hardware data hash and signature in accordance with the SHA-1 cryptographic algorithm using no cryptographic key that meets the Secure Hash Standard, FIPS PUB 180-1, 17th April, 1995.
!
!
122
The TSF shall perform hardware data encryption and decryption in accordance with the:
!
RSA without CRT cryptographic algorithm using 512-bit, 1024-bit, 2048-bit cryptographic key sizes that meets no standard. RSA with CRT cryptographic algorithm using 512-bit, 1024-bit, 2048-bit cryptographic key sizes that meets no standard.
!
5.2.15
123
Cryptographic Key Generation (FCS_CKM.1)
The TSF shall generate cryptographic keys in accordance with cryptographic key generation Miller-Rabin algorithm with confidence criteria (t) between 0 and 255 and specified cryptographic key sizes 512-bit, 1024-bit, 2048-bit (respectively 2 primes of
Matthieu Robert (0450327)
46 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Security Functional Requirements
256 bits, 512 bits and 1024 bits) specified by the NIST special publication 800-2, April 1991.
5.3
Functional Requirements Applicable to PMT in Phase 4 to 7 Only
5.3.1
124
User Authentication Before any Action (FIA_UAU.2)
The TOE security functions shall require each user to be successfully authenticated before allowing any other TOE security functions-mediated actions on behalf of that user.
5.3.2
125
User Identification Before any Action (FIA_UID.2)
The TOE security functions shall require each user to identify itself before allowing any other TOE security functions mediated actions on behalf of that user.
5.3.3
126
User Attribute Definition (FIA_ATD.1)
The TOE security functions shall maintain the following list of security attributes belonging to PMT users:
! ! ! ! ! ! ! !
Package mode access right Limited write EEPROM access right Limited write Flash access right Limited read EEPROM access right Limited read Flash access right EEPROM internal signal access (charge pump and margin) ISO clock access right Clock selection right
127
The write to EEPROM and Flash access is limited to the following:
! ! !
Full erase and program Chip erase and program Page mode write (no further information given in ST-Lite)
128
The read from EEPROM and Flash access is limited to the following
!
Page mode read
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 47 of 68
AT90SC7272C Security Target
5.4
129
TOE Security Assurance Requirements
The assurance requirement is EAL4 augmented of additional assurance components listed in the following sections. Some of these components are hierarchical ones to the components specified in EAL4. All the components are drawn from Common Criteria Part 3, V2.1.
130 131
5.4.1
ADV_IMP.2 Implementation of the TSF
Developer actions elements
132
The developer shall provide the implementation representation for the entire TOE security functions.
Content and presentation of evidence elements
133
The implementation representation shall:
!
Unambiguously define the TOE security functions to a level of detail such that the TOE security functions can be generated without further design decisions Be internally consistent Describe the relationships between all portions of the implementation
! !
Evaluator actions elements
134
The evaluator shall:
!
Confirm that the information provided meets all requirements for content and presentation of evidence. Determine that the implementation representation is an accurate and complete instantiation of the TOE security functional requirements.
!
5.4.2
ALC_DVS.2 Sufficiency of Security Measures
Developer actions elements
135
The developer shall produce development security documentation.
Content and presentation of evidence elements
136
The development security documentation shall:
Matthieu Robert (0450327)
48 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Security Functional Requirements
!
Describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. Provide evidence that these security measures are followed during the development and maintenance of the TOE.
!
137
The evidence shall justify that the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE.
Evaluator actions elements
138
The evaluator shall confirm that the:
!
Information provided meets all requirements for content and presentation of evidence Security measures are being applied
!
5.4.3
AVA_VLA.4 Highly Resistant
Developer actions elements
139
The developer shall:
! !
Perform a vulnerability analysis. Provide vulnerability analysis documentation.
Content and presentation of evidence elements
140
The documentation shall:
!
Describe the analysis of the TOE deliverables performed to search for ways in which a user can violate the TSP. Describe the disposition of identified vulnerabilities. Show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE. Justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks. Show that the search for vulnerabilities is systematic. Provide a justification that the analysis completely addresses the TOE deliverables.
! !
!
! !
Evaluator actions elements
141
The evaluator shall:
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 49 of 68
AT90SC7272C Security Target
!
Confirm that the information provided meets all requirements for content and presentation of evidence Conduct penetration testing, building on the developer vulnerability analysis, to ensure the identified vulnerabilities have been addressed. Perform independent vulnerability analysis Perform independent penetration testing, based on the independent vulnerability analysis, to determine the exploitability of additional identified vulnerabilities in the intended environment. Determine that the TOE is resistant to penetration attacks performed by an attacker possessing a high attack potential.
!
! !
!
Matthieu Robert (0450327)
50 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Section 6
TOE Summary Specification
142
This section defines the TOE security functions, and Figure 6-1 on page 56 specifies how they satisfy the TOE security functional requirements.
6.1
6.1.1
143
TOE Security Functions
Test Mode Entry (SF1)
SF1 shall ensure that only authorized users will be permitted to enter Test Mode. This is provided by Test Mode Entry conditions that are required to enable the TOE to enter Test Mode. All test entry requirements occur while the TOE is held in reset and failure in any one will prevent Test Mode Entry. It is required that the TOE satisfies the test entry conditions during any internal reset condition. It is not possible to move from User Mode to Test Mode. Any attempt to do this, for example, by forcing internal nodes will be detected and the security functions will disable the ability to enter Test Mode. The Strength of Function claimed for the Test Mode Entry security function is high.
144
145
146
6.1.2
147
Protected Test Memory Access (SF2)
SF2 shall ensure that, although authenticated users can have access to memories using commands in test mode, they cannot access directly their contents. Only authorized design and production engineers running tests on the TOE will have access to the TME conditions. The Strength of Function claimed for the Protected Test Memory Access security function is high.
148
149
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 51 of 68
AT90SC7272C Security Target
6.1.3
150
Test Mode Disable (SF3)
SF3 shall make provision for:
!
Wafer sawing which, once done, shall ensure that none of the test features are available, not even to authenticated users in test mode. Although Package Mode Entry (PME) is now available. Test Mode Disable master fuses which, once blown, shall ensure that none of the test features are available, not even to authenticated users in test mode.
!
6.1.4
151
TOE Testing (SF4)
SF4 shall provide embedded hardware test circuitry with high fault coverage to prevent faulty devices being released in the field. Devices with manufacturing problems (short circuits, open nets, ...) could lead to a poor level of security by disabling some security functions. Testing of security functions is dependent on a fault free and fully functional TOE. The standard cell logic (including the MCU) is tested by functional tests, run from the EEPROM, using test software loaded under the control of the test interface circuit. The Flash is tested through a standard test interface by external stimulus. The EEPROM is tested through a standard test interface by external stimulus. CPU to EEPROM data flow will also be tested by functional tests, run from the EEPROM, using test software loaded under the control of the test interface circuit. To conform with ISO 7816 standards the TOE embedded software will always return an Answer-To-Reset command via the serial I/O port. This contains messages with information on the integrity and identification of the device. An ATR also verifies significant portions of device hardware (CPU, Flash, EEPROM and logic).
152
153 154
155
6.1.5
156 157
Data Error Detection (SF5)
SF5 shall provide means for performing data error detection. Means of performing checksum error detection and parity error detection is provided. The 32-bit Checksum Accelerator or the CRC-16 hardware peripheral can be used by the embedded software to compute fast data error detection on the program and/or data memories before starting any operation.
6.1.6
158
FireWall (SF6)
SF6 shall enforce access control based on the FireWall rules as defined in the ACSF_Policy.
Matthieu Robert (0450327)
52 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Summary Specification
Memory protection
159
The FireWall defines different modes to execute embedded software (supervisor/nonsupervisor) The embedded software is split into two segments: a supervisor Operating System, and a non-supervisor application. The supervisor segment defines by software the limits of the non-supervisor segment. If a protected address is accessed by the non-supervisor software, a security action is invoked.
Illegal address
160
161
162
If an illegal address is accessed, a security action is invoked.
Illegal opcode
163
If an attempt is made to execute any opcode that is not implemented in the instruction set, a security action is invoked.
6.1.7
164
Event Audit (SF7)
The TOE shall provide an Event Audit security function (SF7) to enforce the following rules for monitoring audited events. Accumulation or combination of the following auditable events would indicate a potential security violation. 1. The external voltage supply goes outside acceptable bounds 2. The external clock signal goes outside acceptable bounds 3. The ambient temperature goes outside acceptable bounds 4. Application program abnormal runaway 5. Attempts to physically probe the device 6. Attempts to gain illegal access to reserved RAM memory locations 7. Attempts to gain illegal access to reserved EEPROM memory locations 8. Attempts to gain illegal access to reserved peripheral or IO register locations 9. Attempts to execute illegal instruction "LPM" to read the program memory from the non-supervisor program location 10. Attempts to move the RAM stack to an illegal RAM memory location defined by SPHLC and SPLLC registers 11. Attempts to execute an AVR opcode that is not implemented
165
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 53 of 68
AT90SC7272C Security Target
12. Attempts to illegally write access the device's EEPROM 13. Attempts to illegally write access the device's Flash 14. Attempts to gain illegal access to P0-supervisor or P1-supervisor modes 15. Exposure to UV light goes outside acceptable bounds
166
The Strength of Function claimed for the Event audit security function is high.
6.1.8
167
Event Action (SF8)
SF8 shall provide an Event Action security function to register occurrences of audited events and take appropriate action. Detection of such occurrences will cause an information flag to be set, and may cause one of the following to occur if warranted by the violation:
! ! !
Memory wiping actions Different levels of immediate resets Different levels of security interrupts
168
Event Action depends on the type of Event (see [TD] for more information).
6.1.9
169
Unobservability (SF9)
SF9 shall ensure that users/third parties will have difficulty observing the following operations on the TOE by the described means. 1. Monitoring power consumption in an attempt to extract information relating to any specific resource or service which is being used. 2. Extracting information, relating to any specific resource or service being used by, carrying out timing analysis on cryptographic functions. 3. Extracting information, relating to any specific resource or service being used, by using mechanical, electrical or optical means, in order to examine the topologyof the TOE, including address and databuses and regular structures.
170
The Strength of Function claimed for the Unobservability security function is high.
6.1.10
171
Cryptography (SF10)
The TSF shall provide a cryptographic algorithm to be able to transmit and receive objects in a manner protected from data retrieval or modification. The TSF shall provide hardware DES, TDES data encryption/decryption capability, and SHA-1 data signing capability. The TSF shall also provide hardware RSA without CRT (i.e. modular exponentiation) data encryption/ decryption capability, as well as RSA with CRT data encryption/decryption [TBX].
172
Matthieu Robert (0450327)
54 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Summary Specification
173
Those may be used by the smartcard embedded software to support data encryption and decryption for maintaining data integrity, and protect against sensitive data unauthorized disclosure. The TSF shall provide a Random Number Generator (RNG) to support security operations performed by cryptographic applications. This RNG shall not be predictable, have sufficient entropy, and not leaking information related to the value of the generated random numbers as this leakage could be used to retrieve cryptographic keys for instance. The TSF shall provide RSA cryptographic key generation capability using Miller Rabin algorithm with confidence criteria (t parameter) between 0 and 255. The Strength of Function claimed for the cryptography security function is high. An assessment of the strength of the following algorithms does not form part of the evaluation:
! ! ! ! ! !
174
175
176 177
DES algorithm TDES algorithm SHA-1 algorithm RSA without CRT algorithm RSA with CRT algorithm Miller Rabin algorithm
178
The TSF shall also provide cryptographic primitives to ease the customer proprietary software implementation of these algorithms (multiply, square, ...) as well as DSA and EC-DSA data signature in the AVR embedded software.
6.1.11
179
Package Mode Entry (SF11)
SF11 shall ensure only authorized users will be permitted to enter Package Mode. Failure to meet these conditions will prevent entry into Package Mode. It is not possible to enter Test Mode on a sawn wafer, only Package Mode can be entered. On entering Package Mode the device performs a full NVM erase. This function is protected by Package Mode entry NVM erase. The Strength of Function for the Package Mode Entry function is high.
180
181
182
6.1.12
183
Test Memory Access in Package Mode (SF12)
SF12 shall ensure that, although authenticated users can have access to memories using commands in package mode, they cannot access directly their contents.
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 55 of 68
AT90SC7272C Security Target
184
When package mode is entered a full EEPROM and Flash erase is performed. Access to the device memories are limited by test algorithms. The memory access information for Package Mode is not given in the Security Target Lite. The Strength of Function claimed for the Protected Test Memory Access in Package Mode is high.
185
186
6.1.13
187
Security Functions Based on Permutations/combinations
The description of the security functions using permutations and/or combination properties is not disclosed in this document.
Table 6-1
Relationship Between Security Requirements and Security Functions
Security Functions
Test Memory Access in Package Mode SF12 x x x x x
Protected Test Memory Access
SF10
SF1
SF2
SF3
SF4
SF5
SF6
SF7
SF8
FIA_UAU.2 FIA_UID.2 FIA_ATD.1 FPT_TST.1 FDP_SDI.1 FMT_MOF.1 FMT_MSA.1 FMT_SMR.1 FMT_SMF.1 FMT_MSA.3 FDP_ACC.2
O1 O2 O3 O4 O5 O6 O7 O8 O9 10 O11
x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
SF9
Security Requirement
Matthieu Robert (0450327)
56 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
SF11 x x x x x x
Package Mode Entry
Data Error Detection
Test Mode Disable
Test Mode Entry
Unobservability
Cryptography
Event Action
TOE Testing
Event Audit
FireWall
TOE Summary Specification
Table 6-1
Relationship Between Security Requirements and Security Functions (Continued)
x x x x x x x x x x x x x x x x x x x x x x x x x x x
FDP_ACF.1 FDP_IFC.1 FDP_IFF.1 FAU_SAA.1 FPR_UNO.1 FPT_PHP.2 FPT_PHP.3 FCS_COP.1 FCS_CKM.1
O12 O13 O14 O15 O16 O17 O18 O19 O20
6.2
188
TOE Assurance Measures
This section defines the TOE assurance measures and Figure 6-2 on page 59 specifies how they satisfy the TOE security assurance requirements.
6.2.1
189
Security Target Lite (SA1)
SA1 shall provide the "AT90SC7272C Security Target Lite" document plus its references.
6.2.2
190
Configuration Management (SA2)
SA2 shall provide the "AT90SC7272C CC Configuration Management (ACM)" interface document plus its references.
6.2.3
191
Delivery and Operation (SA3)
SA3 shall provide the "AT90SC7272C CC Delivery and Operation (ADO)" interface document plus its references.
6.2.4
192
Development Activity (SA4)
SA4 shall provide the "AT90SC7272C CC Development Activity (ADV)" interface document plus its references.
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 57 of 68
AT90SC7272C Security Target
6.2.5
193
Guidance (SA5)
SA5 shall provide the "AT90SC7272C CC Guidance (AGD)" interface document plus its references.
6.2.6
194
Life Cycle Support (SA6)
SA6 shall provide the "AT90SC7272C CC Life Cycle Support (ALC)" interface document plus its references.
6.2.7
195
Test Activity (SA7)
SA7 shall provide the "AT90SC7272C CC Test Activity (ATE)" interface document plus its references, and undertaking of testing described therein.
6.2.8
196
Vulnerability Assessment (SA8)
SA8 shall provide the "AT90SC7272C CC Vulnerability Assessment (AVA)" interface document plus its references, and undertaking of vulnerability assessment described therein.
6.2.9
197
Smart Card Devices (SA9)
SA9 shall provide functional AT90SC7272C smart card devices.
6.2.10
198
Development Site (SA10)
SA10 shall provide access to the development site.
6.2.11
199
Test Site (SA11)
SA11 shall provide access to the test site.
6.2.12
200
Manufacturing Site (SA12)
SA12 shall provide access to the manufacturing site.
6.2.13
201
Sub-contractor Sites (SA13)
SA13 shall provide access to the sub-contractor sites.
Matthieu Robert (0450327)
58 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
TOE Summary Specification
Table 6-2
Relationship Between Assurance Requirements and Measures
Configuration Management
Vulnerability assessment
Delivery and Operation
Development Activity
Security Target Lite
SA10
SA11
SA12
x x x x x x x x
ASE_xxx ACM_AUT.1 ACM_CAP.4 ACM_SCP.2 ADO_DEL.2 ADO_IGS.1 ADV_FSP.2 ADV_HLD.2 ADV_IMP.2 ADV_LLD.1 ADV_RCR.1 ADV_SPM.1 AGD_ADM.1 AGD_USR.1 ALC_DVS.2 ALC_LCD.1 ALC_TAT.1 ATE_COV.2 ATE_DPT.1 ATE_FUN.1 ATE_IND.2 AVA_MSU.2 AVA_SOF.1 AVA_VLA.4
x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 59 of 68
SA13
SA1
SA2
SA3
SA4
SA5
SA6
SA7
SA8
SA9
Assurance Requirement
Manufacturing Site
Smartcard Devices
Life Cycle Support
Development Site
Test Activity
Guidance
Test Site
Sub-contractor Site
AT90SC7272C Security Target
Matthieu Robert (0450327)
60 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Section 7
PP Claims
7.1
202
PP Reference
This Security Target Lite is compliant with CC Smartcard Integrated Circuit Protection Profile PP/9806, Version 2.0, Issue September 1998, and has been registered at the French Certification Body.
7.2
203
PP Refinements
None.
7.3
PP Additions
7.3.1
204
Cryptographic Capability
In addition to conforming to PP/9806, this Security Target Lite specifies an additional Organizational Security Policy P.CRYPTO in Section 3.4. and an additional objective O.CRYPTO in Section 4.1. The CC security functional requirements to meet this Organizational Security Policy are Cryptographic Operation (FCS_COP.1) and Cryptographic key generation (FCS_CKM.1), which are specified in Section 5. The security function to satisfy the FCS_COP.1 and FCS_CKM.1 requirements is SF10 and is specified in Section 6.
205
206
7.3.2
207 208
Specification of Management Functions
This is an addition to the Security Management Class (FMT) The security functions that satisfy the FMT_SMF.1 requirement are SF1, SF3, SF6 and SF11. These security functions are described in Section 6.
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 61 of 68
AT90SC7272C Security Target
Matthieu Robert (0450327)
62 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Appendix A
Glossary
A.1
Terms
BIST
Built In Self Test. Hardware implementation of an algorithm which tests for stuck at, transition, coupling and address faults in a memory Reserved bytes of EEPROM which can be programmed with traceability information. Algorithm used to compute powerful checksum on memory blocks A high-density form of non-volatile memory. Manufacturing Unix based batch Tracking System. Transformation of a string of characters into a usually shorter fixed length value or key that represents the original string. IC Proprietary software which is required for testing purposes and to implement special functions. For AT90SC7272C this includes the embedded test software and additional test programmes which are run from outside of the IC. The Crypto libraries also form part of the IC dedicated software.
Control Bytes CRC-16 Flash FACTORYworks HASH
IC Dedicated Software
IC Designer
Institution (or its agent) responsible for the IC Development. Atmel is the institution in respect of the TOE. Institution (or its agent) responsible for the IC manufacturing, testing and pre-personalization. Atmel is the institution in respect of the TOE. Institution (or its agent) responsible for the IC packaging and testing.
IC Manufacturer
IC Packaging Manufacturer
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 63 of 68
AT90SC7272C Security Target
IC Pre-personalization Data
Required information to enable the smartcard IC to be configured by means of ROM options and to enable programming of the EEPROM with customer specified data. Electronic component(s) designed to perform processing and/or memory functions. Algorithm which tests for stuck at, transition, coupling and address faults in a memory. Algorithm which tests for stuck at, transition, coupling and address faults in a memory. Institution (or its agent) responsible for the smartcard personalization and final testing. A credit sized plastic card which has a non volatile memory and a processing unit embedded within it. Software embedded in the smartcard application (smartcard application software). This software is provided by smartcard embedded software developer (customer). Embedded software may be in any part of User ROM or EEPROM. Smartcard Embedded software is not applicable in the case of the TOE since it is a hardware evaluation only.
Integrated Circuit (IC) MARCH LR MARCH Y Personalizer Smartcard Smartcard Embedded Software
Smartcard Embedded Software Developer Smartcard Issuer Smartcard Product Manufacturer UNIX
Institution (or its agent) responsible for the smartcard embedded software development and the specification of pre-personalization requirements. Institution (or its agent) responsible for the smartcard product delivery to the smartcard end-user. Institution (or its agent) responsible for the smartcard product finishing process and testing. Interactive Time Sharing Operating System.
Matthieu Robert (0450327)
64 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Glossary
A.2
Abbreviations
ACSF AVR BIST CC CPU CRC DES DPA EEPROM EKB FIB HCMOS I/O IC IFCSF ISO LFSR MAC MCU NVM OTP P0 P1 PME PP RAM RFO RISC RNG ROM SPA
Access Control Security Functions 8-bit RISC processor developed and produced by Atmel Built-in Self Test Common Criteria Central Processing Unit Cyclic Redundancy Check Data Encryption Standard Differential Power Analysis Electrically Erasable Programmable ROM East Kilbride Focussed Ion Beam High Speed Complementary Metal Oxide Semiconductor Input/Output Integrated Circuit Information Flow Control Security Functions International Standards Organization Linear Feedback Shift Register Master Authentication Key Microcontroller Non Volatile Memory One Time Programmable ROM Program Supervisor EEPROM Program Supervisor Package Mode Entry Protection Profile Random-Access Memory Rousset France Operations Reduced Instruction Set Core Random Number Generator Read-Only Memory Simple Power Analysis
Matthieu Robert (0450327)
(08 Dec 04) TPG0054A Atmel Confidential Proprietary 65 of 68
AT90SC7272C Security Target
TD TME TOE VFO
Technical Data Test Mode Entry Target of Evaluation Variable Frequency Oscillator
Matthieu Robert (0450327)
66 of 68 Atmel Confidential Proprietary (08 Dec 04) TPG0054A
Matthieu Robert (0450327)
Atmel Corporation
2325 Orchard Parkway San Jose, CA 95131, USA Tel: 1(408) 441-0311 Fax: 1(408) 487-2600
Atmel Operations
Memory
2325 Orchard Parkway San Jose, CA 95131, USA Tel: 1(408) 441-0311 Fax: 1(408) 436-4314
RF/Automotive
Theresienstrasse 2 Postfach 3535 74025 Heilbronn, Germany Tel: (49) 71-31-67-0 Fax: (49) 71-31-67-2340 1150 East Cheyenne Mtn. Blvd. Colorado Springs, CO 80906, USA Tel: 1(719) 576-3300 Fax: 1(719) 540-1759
Regional Headquarters
Europe
Atmel Sarl Route des Arsenaux 41 Case Postale 80 CH-1705 Fribourg Switzerland Tel: (41) 26-426-5555 Fax: (41) 26-426-5500
Microcontrollers
2325 Orchard Parkway San Jose, CA 95131, USA Tel: 1(408) 441-0311 Fax: 1(408) 436-4314 La Chantrerie BP 70602 44306 Nantes Cedex 3, France Tel: (33) 2-40-18-18-18 Fax: (33) 2-40-18-19-60
Biometrics/Imaging/Hi-Rel MPU/ High Speed Converters/RF Datacom
Avenue de Rochepleine BP 123 38521 Saint-Egreve Cedex, France Tel: (33) 4-76-58-30-00 Fax: (33) 4-76-58-34-80
Asia
Room 1219 Chinachem Golden Plaza 77 Mody Road Tsimshatsui East Kowloon Hong Kong Tel: (852) 2721-9778 Fax: (852) 2722-1369
ASIC/ASSP/Smart Cards
Zone Industrielle 13106 Rousset Cedex, France Tel: (33) 4-42-53-60-00 Fax: (33) 4-42-53-60-01 1150 East Cheyenne Mtn. Blvd. Colorado Springs, CO 80906, USA Tel: 1(719) 576-3300 Fax: 1(719) 540-1759 Scottish Enterprise Technology Park Maxwell Building East Kilbride G75 0QR, Scotland Tel: (44) 1355-803-000 Fax: (44) 1355-242-743
Japan
9F, Tonetsu Shinkawa Bldg. 1-24-8 Shinkawa Chuo-ku, Tokyo 104-0033 Japan Tel: (81) 3-3523-3551 Fax: (81) 3-3523-7581
Matthieu Robert (0450327)
Literature Requests
www.atmel.com/literature
Disclaimer: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN ATMEL'S TERMS AND CONDITIONS OF SALE LOCATED ON ATMEL'S WEB SITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Atmel does not make any commitment to update the information contained herein. Atmel's products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.
(c) Atmel Corporation 2004. All rights reserved. Atmel (R), logo and combinations thereof, [insert any additional, applicable Atmel registered marks here] are registered trademarks, and Everywhere You Are SM [insert any additional, applicable Atmel marks here] are the trademarks of Atmel Corporation or its subsidiaries. [insert any 3rd party trademarks according to Legal Requirements]. Other terms and product names may be trademarks of others.
Printed on recycled paper.
TPG0054A-08 Dec 04

▲Up To Search▲

Price & Availability of AT90SC7272C

	To Download AT90SC7272C Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .